Copyright c○2011

ion and Refinement This chapter focuses on relationships between models known as abstraction and refinement. These terms are symmetric in that the statement “model A is an abstraction of model B” means the same thing as “model B is a refinement of model A.” As a general rule, the refinement model B has more detail than the abstraction A, and the abstraction is simpler, smaller, or easier to understand. An abstraction is sound (with respect to some formal system of properties) if properties that are true of the abstraction are also true of the refinement. The formal system of properties could be, for example, a type system, linear temporal logic, or the languages of state machines. If the formal system is LTL, then if every LTL formula that holds for A also holds for B, then A is a sound abstraction of B. This is useful when it is easier to prove that a formula holds for A than to prove that it holds for B, for example because the state space of B may be much larger than the state space of A. An abstraction is complete (with respect to some formal system of properties) if properties that are true of the refinement are also true of the abstraction. For example, if the formal system of properties is LTL, then A is a complete abstraction of B if every LTL formula that holds for B also holds for A. Useful abstractions are usually sound but not complete, because it is hard to make a complete abstraction that is significantly simpler or smaller. Consider for example a program B in an imperative language such as C that has multiple threads. We might construct an abstraction A that ignores the values of variables and replaces all branches and control structures with nondeterministic choices. The abstraction clearly has less information than the program, but it may be sufficient for proving some properties about the program, for example a mutual exclusion property. Lee & Seshia, Introduction to Embedded Systems 355 13.2. TYPE EQUIVALENCE AND REFINEMENT change an implementation, replacing it with another that might, for example, reduce the implementation cost. 13.2 Type Equivalence and Refinement We begin with a simple relationship between two models that compares only the data types of their communication with their environment. Specifically, the goal is to ensure that a model B can be used in any environment where a model A can be used without causing any conflicts about data types. Specifically, we will require that B can accept any inputs that A can accept from the environment, and that any environment that can accept any output A can produce can also accept any output than B can produce. To make the problem concrete, assume an actor model for A and B, as shown in Figure 13.1. In that figure, A has three ports, two of which are input ports represented by the set PA = {x,w}, and one of which is an output port represented by the set QA = {y}. These ports represent communication between A and its environment. The inputs have type Vx and Vw, which means that at a reaction of the actor, the values of the inputs will be members of the sets Vx or Vw. If we want to replace A by B in some environment, the ports and their types impose four constraints: 1. The first constraint is that B does not require some input signal that the environment does not provide. If the input ports of B are given by the set PB, then this is guaranteed by PB ⊆ PA. (13.1) The ports of B are a subset of the ports of A. It is harmless for A to have more input ports than B, because if B replaces A in some environment, it can simply ignore any input signals that it does not need. 2. The second constraint is that B produces all the output signals that the environment may require. This is ensured by the constraint